\section{Conclusions and Future Work} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:cc}

Presented pattern-matching library provides fairly standard functional style 
pattern-matching facilities for \Cpp{}. The solution is open to new patterns, 
with the traditional patterns implemented as an example. It is also 
non-intrusive and can be applied retroactively. %to any polymorphic or tagged 
%class hierarchy. It also provides a uniform notation to these different 
%encodings of algebraic and extensible hierarchical data types in \Cpp{}.
The library provides efficient and expressive matching on multiple subjects and 
compares well to multiple dispatch alternatives in terms of both time and space.
We also offer an alternative interpretation of the n+k patterns and show how some 
traditional generalizations of these patterns can be implemented in our library. 
%to arbitrary expressions by letting the user define   
%the exact semantics of such patterns. Our approach is more general than traditional approaches 
%as it does not require an
%equational view of such patterns. It also avoids hardcoding the 
%exact semantics of n+k patterns into the language. 

We generalize n+k patterns to arbitrary expressions by letting the user define 
the exact semantics of such patterns. Our approach is more general than traditional approaches 
as it does not require an
equational view of such patterns. It also avoids hardcoding the 
exact semantics of n+k patterns into the language. 

%We used the library to rewrite existing code that relied heavily on the 
%visitor design pattern.
%Our pattern matching code was much shorter (both source and object code), 
%simpler, easier to maintain, comprehend, and faster. 
%This confirmed our view of the visitor pattern as a clever workaround,
%rather than a good solution to a fundamental problem.
%The library approach was essential 
%for experimentation in the context of real programs and for delivering 
%performance comparable with or superior to conventional techniques in the 
%context of industrial compilers.

The work presented here continues our research on pattern matching for 
\Cpp{}~\cite{TS12}. In the future we would like to implement an actual language 
extension capable of working with open patterns and look into how code for such 
patterns can be optimized without hardcoding the knowledge of pattern's 
semantics into the compiler. 
We would like to experiment with other kinds of patterns, 
including those defined by the user; look at the interaction of patterns with 
other facilities in the language and the standard library; make
views less ad hoc etc. For example, standard containers in \Cpp{} do not have the 
implicit recursive structure present in data types of functional languages and 
viewing them as such with views would incur significant overheads. We will
experiment with very general patterns as first-class citizens.

%Our generalization of n+k patterns depends on the properties of types involved 
%in the expression. This should let us experiment not only with generic 
%functions, but also with their generic inversions in the form of solvers. As 
%more \Cpp{}11 features become available in compilers it will also be interesting to 
%look at how use of these features affects the ease of use, performance, 
%readability, writability and debugging of the library and the user code that 
%uses it.

%In the nearest future, we would like to make our library to be safe and efficient 
%in a multi-threaded environment. We would also like to look into providing an 
%equally efficient and expressive support to multiple subjects, which in turn 
%would allow us to address asymmetric multiple dispatch.

%From Morten Rhiger:
%New languages are often constructed by piling new features on top of an existing language's de?nition and by integrating these features in the existing language's implementation. However, it is a sign of expressiveness if new features can be implemented within an
%existing language without changing its de?nition.
%Short of macros, functional languages such as Haskell and Standard ML require new
%features to be expressed in terms of typed higher-order functions. We have demonstrated
%how to extend - or, in Guy Steele's terminology, to "grow" (Steele Jr., 1999) - Haskell
%with our own statically typed implementation of pattern matching and we have shown how
%to extend this framework with patterns not currently supported by Haskell.

\subsection{Limitations}
\label{sec:ommlimit}

While our patterns can be saved in variables and passed over to functions, they 
are not true first-class citizens. In fact, we believe that the notion of being 
a first-class citizen in a language should be updated to take parametric 
polymorphism of \Cpp{} into account. The reason is that as is, our solution does
not allow for composing patterns based on user's input (e.g. by letting user 
type in a pattern to match against). This can potentially be solved by mixing 
``patterns as objects'' approach in, however the performance overhead we saw in 
\textsection\ref{sec:patcmp} is too costly to be adopted.
